Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-033.txt

Text File | 1992-11-18 | 46.1 KB | 1,460 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 27 Mar 92       Volume 1 : Issue 33

Today's Topics:

    Yet another horizontal line fill routine...
    MacApp3 & ViewEdit ?
    MPW .o -> ThC 5 library
    Bug in Sys70 SetFPos?
    MoveWindow using unused stack portion as scratch?
    Closing windows in MacApp
    Comm Toolbox problems with THINK C in XCMD environment
    OOP Power for TP Programmers  Was: Re: Book for TCL


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu.  This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail] (Tng Tai Hou)
Subject: Yet another horizontal line fill routine...
Organization: Institute of Systems Science, NUS, Singapore
Date: Mon, 24 Feb 1992 09:22:20 GMT

Here is a new, hopefully improved horizontal line fill routine. workable only
for 8-bits displays.
The variable value is a longword with each of its bytes containing similar
8-bit color index information.

This version checks for long word alignment and fills accordingly.
I have released two versions, a 'c' version with simple assembly, and a
hand-tuned assembly version. Again, as in my previous posting, I would
appreciate if you kind folks could give me your feedback. Have I make
the best of 68020 instruction set and whatever caches there are on these
chips? If you spot any bugs, or perhaps if it doesn't perform longword
alignment fills etc, do let me know.

Your help is very much appreciated.
Thanks.

Tai Hou
Singapore

- ------------------

void
MyAAAMemSet (register unsigned long *buf, register unsigned long value,
             register unsigned long count)
{
    register long rem;
    register int i;
    register long remBuf;

    if (count < 4)
    {
        for (i=0; i<count; i++)
        {
            asm {
                move.b    value, (buf)+
            }
        }
    }
    else {
        remBuf = 4 - (long)buf % 4;
        remBuf %= 4;

        for (i=0; i<remBuf; i++)
        {
            asm {
                move.b    value, (buf)+
            }
        }
        count -= remBuf;
         rem = count % 4;
        if (rem == 0)
        {
            for (i=0; i<count; i+=4)
                *buf++ = value;
        }
        else {
            count &= 0xFFFFFFFC;
            for (i=0; i<count; i+=4)
                *buf++ = value;
            for (i=0; i<rem; i++)
            {
                asm {
                    move.b    value, (buf)+
                }
            }
        }
    }
}


/* count != 0 */
void
A1_MemSet (/*register unsigned long *buf, register unsigned long value,
register unsigned long count*/)
{
    asm {
                movem.l    4(sp),    d0-d2        /* d0 = buf, d1 = value, d2 = count
*/
                movea.l    d0,        a0            /* ao = d0 */

                cmp.l    #4,        d2
                bge        @GE4

                movea.l    d2,    a1                /* a1 = p */
                add.l    a0,    a1
        @a0:    move.b    d1,    (a0)+
                cmp.l    a0,    a1
                bne        @a0
                bra        @end

        @GE4:    move.l    a0,    d3            /* d3 = remBuf */
                andi.l    #3,        d3
                subq.l    #4,        d3
                neg.l    d3
                andi.l    #3,        d3
                beq        @REMBUF0

                movea.l    d3,    a1
                add.l    a0,    a1
        @a1:    move.b    d1,    (a0)+
                cmp.l    a0,    a1
                bne        @a1

        @REMBUF0:
                sub.l    d3,    d2
                move.l    d2,    d5            /* d5 = rem */
                andi.l    #3,        d5
                bne        @REMNOT0

                movea.l    d2,    a1
                add.l    a0,    a1
        @a2:    move.l    d1,    (a0)+
                cmp.l    a0,    a1
                bne        @a2
                bra        @end

        @REMNOT0:
                andi.l    #0xFFFFFFFC,    d2
                cmp.l    #0x0,    d2
                beq        @a4
                movea.l    d2,    a1
                add.l    a0,    a1
        @a3:    move.l    d1,    (a0)+
                cmp.l    a0,    a1
                bne        @a3

        @a4:    movea.l    d5,    a1
                add.l    a0,    a1
        @a5:    move.b    d1,    (a0)+
                cmp.l    a0,    a1
                bne        @a5
        @end:
    }
}



---------------------------

From: [e-mail] (Don Gilbert)
Subject: MacApp3 & ViewEdit ?
Date: 10 Feb 92 22:22:10 GMT
Organization: Biology, Indiana University - Bloomington


I am ready to think about switching from MacApp 2 to
MacApp 3.  I notice that 'view' is switching to 'View',
a different view format.  I rely heavily on ViewEdit
to build displays.  Will ViewEdit be supported for MacApp 3?
Will the current version work with MacApp 3 Views
(i haven't tried)?

Thanks,  Don

P.s., If ViewEdit is upgraded, please make the
"[x] use horizontal/vertical grid" a sticky user preference
or else change the default to "[ ]" (don't use grid).
I hate having to change those buttons each time I edit
a view.
--
Don Gilbert                                     [e-mail]
biocomputing office, biology dept., indiana univ., bloomington, in 47405



- -------------------------

From: [e-mail] (Alex Smith)
Subject:  MacApp3 & ViewEdit ?
Date: 12 Feb 92 00:54:19 GMT
Organization: The Jackson Laboratory

In article <[e-mail]> [e-mail] (Don Gilbert) writes:
>
>I am ready to think about switching from MacApp 2 to
>MacApp 3.  I notice that 'view' is switching to 'View',
>a different view format.  I rely heavily on ViewEdit
>to build displays.  Will ViewEdit be supported for MacApp 3?
>Will the current version work with MacApp 3 Views
>(i haven't tried)?

    No. It can only edit 'view' resources. But there's a utility called
    "ViewPromoter" (with MacApp 3.0) that converts 'view' resources to their
    'View' equivalents. It works reasonably well. The version on ETO #5 does
    not handle all things, so prepare yourself to use Rez to patch up your
    'Views'. (Can't speak for the version with 3.0b3 -- I just got the CD
    yesterday.) In any case MacApp 3.0 understands both types (for now).

    ViewEdit 3.0d11 was distributed to the MacApp3Beta$ list on AppleLink
    in December, but didn't make it into ETO #6. Perhaps Kent would
    be kind enough to put it somewhere on AppleLink where others can
    find it :-).

>
>Thanks,  Don
>
>P.s., If ViewEdit is upgraded, please make the
>"[x] use horizontal/vertical grid" a sticky user preference
>or else change the default to "[ ]" (don't use grid).
>I hate having to change those buttons each time I edit
>a view.
>--
>Don Gilbert                                     [e-mail]
>biocomputing office, biology dept., indiana univ., bloomington, in 47405


Alex Smith                Internet: [e-mail]
The Jackson Laboratory            AppleLink: A.G.SMITH



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  MacApp3 & ViewEdit ?
Date: 13 Feb 92 01:32:33 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Don Gilbert) writes:
>
>
> I am ready to think about switching from MacApp 2 to
> MacApp 3.  I notice that 'view' is switching to 'View',
> a different view format.  I rely heavily on ViewEdit
> to build displays.  Will ViewEdit be supported for MacApp 3?
> Will the current version work with MacApp 3 Views
> (i haven't tried)?

The MacApp 3.0 final distribution will have ViewEdit 3.0, which
will read and write 'View' resources. ETO#7 out in March will have
MacApp 3.0 final - the framework.

If you like IcePick, there's a ViewPromoter tool which will convert
'view' resources to 'View' ones. Also, speaking from a practical
point of view it seems that I mostly write the first resource hacks using IcePick,
do some fine tuning using ViewEdit 3.0, and finally do the low level
nitty-picky tuning with text versions of the 'View' resources.

The MacApp 3.0b3 had the possibility to read 'view' style resources
if you recompiled the framework with suitable flags, but I'm not
100% this is the case with 3.0 final.

Kent Sandvik/DTS
(gc)
(gc!!!)



- -------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject:  MacApp3 & ViewEdit ?
Date: 14 Feb 92 07:10:50 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>The MacApp 3.0 final distribution will have ViewEdit 3.0, which
>will read and write 'View' resources. ETO#7 out in March will have
>MacApp 3.0 final - the framework.

Although this is a marketing question, let me ask : Will MacApp 3.0
be offered separately, outside ETO? ETO becomes too expensive
outside the U.S.A.. (Not for commercial developers, but I think
non-commercial developers would also like to have it. :-) )


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  MacApp3 & ViewEdit ?
Date: 14 Feb 92 07:51:51 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Alex Smith) writes:
>     No. It can only edit 'view' resources. But there's a utility called
>     "ViewPromoter" (with MacApp 3.0) that converts 'view' resources to their
>     'View' equivalents. It works reasonably well. The version on ETO #5 does
>     not handle all things, so prepare yourself to use Rez to patch up your
>     'Views'. (Can't speak for the version with 3.0b3 -- I just got the CD
>     yesterday.) In any case MacApp 3.0 understands both types (for now).

>     ViewEdit 3.0d11 was distributed to the MacApp3Beta$ list on AppleLink
>     in December, but didn't make it into ETO #6. Perhaps Kent would
>     be kind enough to put it somewhere on AppleLink where others can
>     find it :-).

If I would be a 20-year-old Kent Sandvik with rebel blood in my veins
I would do it. But I have a nine month old son and a wife and I need to
keep my job in our one-income family :-). Anyway, if Tom Chavez says
OK we might upload it on AppleLink...

Just to mention a secret, ViewEdit 3.0b2 will be on ETO#7, out in March.
I'm using IcePick, and I'm doing the final touches  with raw 'View'
text format (yes, we need to document the 'View' format...).

Kent Sandvik/DTS



- -------------------------

From: [e-mail] (Kent Sandvik)
Subject:  MacApp3 & ViewEdit ?
Date: 17 Feb 92 03:01:29 GMT
Organization: MacDTS Mongols

In article <[e-mail]>, [e-mail] (Levent Mollamustafaoglu) writes:
> In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
> >The MacApp 3.0 final distribution will have ViewEdit 3.0, which
> >will read and write 'View' resources. ETO#7 out in March will have
> >MacApp 3.0 final - the framework.

> Although this is a marketing question, let me ask : Will MacApp 3.0
> be offered separately, outside ETO? ETO becomes too expensive
> outside the U.S.A.. (Not for commercial developers, but I think
> non-commercial developers would also like to have it. :-) )

No problems, it will be available as an APDA product. The difference compared
with ETO CDs is that the documentation has to be ready before APDA ships the
product. We are able to release 3.0 final on ETOs without worrying about
paper documentation. I don't know the exact dates when 3.0 is an APDA product,
but we are talking about N weeks.

Kent Sandvik/DTS
- -
not speaking for DTS...



- -------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject:  MacApp3 & ViewEdit ?
Date: 18 Feb 92 17:06:23 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Kent Sandvik) writes:
>
>No problems, it will be available as an APDA product. The difference compared
>with ETO CDs is that the documentation has to be ready before APDA ships the
>product. We are able to release 3.0 final on ETOs without worrying about
>paper documentation. I don't know the exact dates when 3.0 is an APDA product,
>but we are talking about N weeks.
>
This might be a FAQ for this group, so excuse me if it was asked before :
Does MacApp 3.0 only have a C++ version?


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  MacApp3 & ViewEdit ?
Date: 25 Feb 92 03:34:17 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Levent Mollamustafaoglu) writes:
>>
>This might be a FAQ for this group, so excuse me if it was asked before :
>Does MacApp 3.0 only have a C++ version?

MacApp 3.0 is written entirely in C++, and will most likely stay that
way. This means that if the pre-compiled libraries that come with
MacApp are not sufficient for you and you need to compile your own
version, you will need C++. However, you can still write your own code
in MPW Pascal if you want; it will link with MacApp just fine.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Levent Mollamustafaoglu)
Subject:  MacApp3 & ViewEdit ?
Date: 25 Feb 92 06:44:40 GMT
Organization: Aiken Computation Lab, Harvard University

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>In article <[e-mail]> [e-mail] (Levent Mollamustafaoglu) writes:
>>>
>>This might be a FAQ for this group, so excuse me if it was asked before :
>>Does MacApp 3.0 only have a C++ version?
>
>MacApp 3.0 is written entirely in C++, and will most likely stay that
>way. This means that if the pre-compiled libraries that come with
>MacApp are not sufficient for you and you need to compile your own
>version, you will need C++. However, you can still write your own code
>in MPW Pascal if you want; it will link with MacApp just fine.
>
So this seems to rule out Think Pascal, unless it can directly use
MPW libraries, which I doubt.


===========================================================================
Dr. Levent Mollamustafaoglu       Harvard University
[e-mail]    [e-mail]
===========================================================================



- -------------------------

From: [e-mail] (Mark Wilkins)
Subject:  MacApp3 & ViewEdit ?
Date: 25 Feb 92 13:30:51 GMT
Organization: Harvey Mudd College, Claremont, CA 91711

In article <[e-mail]> [e-mail] (Levent Mollamustafaoglu) writes:
>So this seems to rule out Think Pascal, unless it can directly use
>MPW libraries, which I doubt.

  No.  Can't you just add MPW object files to THINK Pascal projects using
the same command you would use to add a source file?

  I spent hours trying to find the oConv utility on the THINK Pascal disks
and finally called tech support. :-)

-- Mark Wilkins
--
- -----------------------------------------------------------------------------
"Do your schools offer, and would you consider taking,  |       Mark R. Wilkins
remedial courses in spelling and grammar?  This is one  | wilkins@jarthur.
area where your 28 or 48 can't help you."               |         claremont.edu



---------------------------

From: [e-mail] (Corp Reed)
Subject: MPW .o -> ThC 5 library
Date: 15 Feb 92 20:09:04 GMT
Organization: none

I have a rather large MPW .o file that I want to convert to a Think C
library.  I have looked at the manuals and couldn't find any obvious way
to do this.  The library is too large for oConv to work on.

Is it possible to just convert part of the library and use it to call
the other part w/some weird MPW compiling option?  Would there be any significant reason why this wouldn't work?

-C Reed.
Mac Programming Junkie.



- -------------------------

From: [e-mail] (Roger W. Brown)
Subject:  MPW .o -> ThC 5 library
Date: 25 Feb 92 16:01:23 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Corp Reed) writes:

> I have a rather large MPW .o file that I want to convert to a Think C
> library.  I have looked at the manuals and couldn't find any obvious way
> to do this.  The library is too large for oConv to work on.

The documentation for THINK C 5.0 tells how. See chapter 16 of the user
manual. (I have never tried it myself.)


- ---------------------------------------------------------------
Roger Brown                           [e-mail]
Courseware Development
Dartmouth College, Hanover, NH



---------------------------

From: [e-mail] (Bernie Wieser)
Subject: Bug in Sys70 SetFPos?
Date: 17 Feb 92 03:38:59 GMT
Organization: The University of Calgary, Alberta, Canada

I noticed something strange under System 7.0 and I am wondering if this
is a bug or a feature.  I do not remember having this trouble under system
6.

When I am reading in a buffer and an EOF is reached, SetFPos will no longer
function.  It too will return an EOF error.  For example, let's say you
have a file 128 bytes long and do the following (assume the file is open
and you are at pos 0)
long count = 256;
err = FSRead(fd, &count, &buffer);
err = SetFPos(fd, fsFromStart, 0);
The SetFPos will fail, regardless of a low level (PB) or library call.
I do not recall reading that reaching EOF effectively closes the file
in InsideMac.  Is something wrong or is it just me?


--



- -------------------------

From: [e-mail] (John Snook)
Subject:  Bug in Sys70 SetFPos?
Organization: University of Illinois at Urbana
Date: Wed, 19 Feb 1992 05:45:23 GMT

[e-mail] (Bernie Wieser) writes:


>When I am reading in a buffer and an EOF is reached, SetFPos will no longer
>function.  It too will return an EOF error.  For example, let's say you

I wrote several database tools that used SetFPos and they all worked fine on
Sys 6, but didn't work under 7. I called Symantec's TS, and they had no advice.
However, I never tried any of the FSS calls. I wonder if you might try those.
I don't have the Behemoth IM vi with me & I can't remember if there is a new
version of SetFPos.
good luck
j snook





- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Bug in Sys70 SetFPos?
Date: 19 Feb 92 11:38:55 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (John Snook) writes:

   >When I am reading in a buffer and an EOF is reached, SetFPos will no longer
   >function.  It too will return an EOF error.  For example, let's say you

   However, I never tried any of the FSS calls. I wonder if you might try those.
   I don't have the Behemoth IM vi with me & I can't remember if there is a new
   version of SetFPos.


No there is not, since the FSS calls handle unopened files, while
setfpos takes a fRefNum (hich hasn't changed since Darwin...)

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Bug in Sys70 SetFPos?
Date: 25 Feb 92 03:38:56 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>> [e-mail] (John Snook) writes:
>
>   >When I am reading in a buffer and an EOF is reached, SetFPos will no longer
>   >function.  It too will return an EOF error.  For example, let's say you
>
>   However, I never tried any of the FSS calls. I wonder if you might try those.
>   I don't have the Behemoth IM vi with me & I can't remember if there is a new
>   version of SetFPos.
>
>No there is not, since the FSS calls handle unopened files, while
>setfpos takes a fRefNum (hich hasn't changed since Darwin...)

Jon answered this question, but I just wanted to point out a handy
tip.  If you don't have IM VI and you want to know the interface to a
certain call, there's no need to post a question to c.s.m.programmer.
Just check your header files (in this case, Files.h or File.p).

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Steven Ritter)
Subject:  Bug in Sys70 SetFPos?
Date: 25 Feb 92 15:24:18 GMT
Organization: Doctoral student, Psychology, Carnegie Mellon, Pittsburgh, PA

>Jon answered this question, but I just wanted to point out a handy
>tip.  If you don't have IM VI and you want to know the interface to a
>certain call, there's no need to post a question to c.s.m.programmer.
>Just check your header files (in this case, Files.h or File.p).

>Keith Rollin           ---            <Taligent .signature under construction>
>Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...

Which brings up a question.  Is there any way in Think C to search all
the Apple header files?  Its frequently not obvious which file has the
prototype.

Steve



- -------------------------

From: [e-mail] (Eric W. Douglas)
Subject:  Bug in Sys70 SetFPos?
Date: 25 Feb 92 17:22:45 GMT


[e-mail] (Steven Ritter) writes:

>>Jon answered this question, but I just wanted to point out a handy
>>tip.  If you don't have IM VI and you want to know the interface to a
>>certain call, there's no need to post a question to c.s.m.programmer.
>>Just check your header files (in this case, Files.h or File.p).

>>Keith Rollin           ---            <Taligent .signature under construction>
>>Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...

>Which brings up a question.  Is there any way in Think C to search all
>the Apple header files?  Its frequently not obvious which file has the
>prototype.

Check out the latest issue of Symantec's magazine/newletter/etc... it has
an article which will tell you how do this. (Sorry, I don't have it with me.)

--eric

* | Eric W. Douglas             Technojock               [phone] | *
* | I'net: [e-mail]      [e-mail] | *
* | AppleLink: STUDIO.D      Compuserve: 76170,1472       AOL: EWDOUGLAS | *
* |                "if q -> p, and not p, then not q. NOT!"              | *




- -------------------------

From: [e-mail] (Stephen Uitti)
Subject:  Bug in Sys70 SetFPos?
Organization: Interactive Systems, Cambridge, MA 02138-5302
Date: Tue, 25 Feb 1992 17:19:34 GMT

>Is there any way in Think C to search all
>the Apple header files?  Its frequently not obvious which file has the
>prototype.

The common way to get this capability is to create a THINK C
project that has a file that includes all the headers.  This
would be a reasonable thing to have in the distrib.  I don't know
why the project file for MacHeaders does not exist.  "Mac
#includes.c" does exist, and could probably be used as a start in
a project for searching.

Of course, someone could make one available for FTP.
While on that topic, a TCLheaders project would be nice.
I have one.

Stephen.
[e-mail]



- -------------------------

From: [e-mail] (Matthew T. Russotto)
Subject:  Bug in Sys70 SetFPos?
Date: Tue, 25 Feb 92 20:43:07 GMT
Organization: University of Maryland, College Park, College of Engineering

In article <[e-mail]> [e-mail] (Steven Ritter) writes:

>Which brings up a question.  Is there any way in Think C to search all
>the Apple header files?  Its frequently not obvious which file has the
>prototype.

Include <mac #includes.c> in some file in your project.  Then the multi-file
find will find them.


--
Matthew T. Russotto    [e-mail]    [e-mail]
Some news readers expect "Disclaimer:" here.
Just say NO to police searches and seizures.  Make them use force.
(not responsible for bodily harm resulting from following above advice)



- -------------------------

From: [e-mail] (Phil Shapiro)
Subject: How to search headers in THINK C (FAQ) [Was: Bug in Sys70 SetFPos?]
Date: 25 Feb 92 20:57:34 GMT
Organization: Symantec Corp.

In article <[e-mail]> [e-mail] (Steven Ritter) writes:

   Is there any way in Think C to search all the Apple header files?
   Its frequently not obvious which file has the prototype.

The easiest way is to just add the source file for your precompiled
header to your project and compile it.  Once you've done that, you can
search all of the header files by bringing up the Find dialog box and
hitting Command-H. This selects all of the header files in your
project, including all of the header files in your precompiled header.

If you're using the default precompile header file, MacHeaders, just
add the file "Mac #includes.c" to your project and compile it.

    -phil
--
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Bug in Sys70 SetFPos?
Date: 25 Feb 92 03:38:56 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>> [e-mail] (John Snook) writes:
>
>   >When I am reading in a buffer and an EOF is reached, SetFPos will no longer
>   >function.  It too will return an EOF error.  For example, let's say you
>
>   However, I never tried any of the FSS calls. I wonder if you might try those.
>   I don't have the Behemoth IM vi with me & I can't remember if there is a new
>   version of SetFPos.
>
>No there is not, since the FSS calls handle unopened files, while
>setfpos takes a fRefNum (hich hasn't changed since Darwin...)

Jon answered this question, but I just wanted to point out a handy
tip.  If you don't have IM VI and you want to know the interface to a
certain call, there's no need to post a question to c.s.m.programmer.
Just check your header files (in this case, Files.h or File.p).

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  Bug in Sys70 SetFPos?
Date: 25 Feb 92 22:48:06 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Steven Ritter) writes:

   Which brings up a question.  Is there any way in Think C to search all
   the Apple header files?  Its frequently not obvious which file has the
   prototype.

Yes:

Include Mac #includes.c in your project ! It takes some time to
compile the first time, but then it generates no code and adds in
all the headers you use.

One good tip: turn OFF SIMPLIFY_PROTOTYPES, turn ON all header
files except one of the print headers, and precompile, giving a
MacHeaders that's about 350k. Now, compilation will go faster
since you won+t have to load any apple headers separately,
everything is available without hassle, AND the think class
library "starter" project file is WAY below 1 meg in size when
compiled ! A great space saver !

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



---------------------------

From: [e-mail] (David Dantowitz)
Subject: MoveWindow using unused stack portion as scratch?
Date: 19 Feb 92 17:42:14 GMT
Organization: UCLA Computer Science Department


/*
The following file contains five routines that demonstrate a problem
I am having with unused portions of my stack being randomly written.
I can't track this thing down to a code bug, but perhaps someone else can.

It appears that MoveWindow is using a portion of the stack (that is currently
unused) for temporary workspace.  It always uses the same offset from the
top address of the stack (GetApplLimit()).  This can be tested by increasing
the stack region.

Any help would be appreciated.  I'm using the stack marking code to calculate
how much stack space my application is using.  (This is for a very complicated
application (3Meg of source) that periodically checks out.  The symptoms are
bad status errors from the SCSI manager (stat values like -3453).  The problem
got better when we switched from an Apollyonics driver to SilverLining, but
the problem remains.  My first guess is stack overflow, which lead me to
the enclosed problem.  My second guess is memory somewhere being overwritten,
and my third guess is bad SCSI Manager calls, but they really look fine.)





_profile_ is a substute profiler routine that I used to track down the
offending stack-writing code.

TestWindow contains two lines of code from the new_console routine in
the console.c file from the THINK C ANSI library.  The problem starts
here.

CheckStack checks to see how much of the stack has been used.

MarkStack marks the stack with an initial pattern

Recurse is a simple routine that just uses stack space


Machine configuration: System 7.0.1, IIci, 4Mb, NO EXTENSIONS, no cache card

Thanks,

David Dantowitz
[e-mail]

*/


/*
Set this constant to 1 to have CheckStack print its results each time.
It was the call to printf in CheckStack that lead me to notice the
code in new_console that was writing to the stack.

Leave this code disabled to use the code in TestWindow first.
*/

#define CHECK_PRINT 0

#include <MacHeaders>

#include <stdio.h>

#define BASESKIP 256                    // Leave this space at the bottom of the stack
#define TOPSKIP 1024                    // Leave this space at the top of the stack


long *base=NULL, *top=NULL;


#pragma options(!profile)

// A profile substitute that checks the stack use

/*
 *  _profile_ - profiler entry point
 *
 *  Each function compiled with the "Profile" option begins with a call
 *  to _profile_("\pfuncname").
 *
 */

void
_profile_(unsigned char *fname);

void
_profile_(unsigned char *fname)
{
    long *i;

    for (i=top; i < base; i++)
        if (*i != 'Mark')
            break;

    i = (long *) (((long *)CurStackBase-i)*4);

    if (top != NULL && (long)i > 20*1024)
        Debugger();

    return;
}


// The following routine contains code that was lifted from console.c:new_console
// from the ANSI C library included with THINK C 5 ()1991 Symantec Corporation)
// This code is where writing to the stack begins.

void
TestWindow(void);

static Rect r={100, 100, 200, 200};

void TestWindow()
{
    WindowPtr window;

    window = NewWindow(0, &r, "\ptitle", 0, 8, (Ptr) -1, 0, 0);
    MoveWindow(window, 100, 100, 0);
}

long
CheckStack(void);                        // Check the stack use

long
CheckStack()                            // Check the stack use
{
    long *i;

    for (i=top; i < base; i++)
        if (*i != 'Mark')
            break;


#if CHECK_PRINT
    printf("%ld bytes used\n", ((long *)CurStackBase-i)*4);
#endif

    return (((long *)CurStackBase-i)*4);
}


void
MarkStack(void);                        // mark the stack

void
MarkStack()                                // mark the stack
{
    long *i;

    base = (long *)(CurStackBase - BASESKIP);        // skip first BASESKIP bytes
    top = (long *)(GetApplLimit() + TOPSKIP);        // skip last TOPSKIP bytes

    base = (long *) ((long) base & -4);                // 4-byte align the values
    top = (long *) ((long) top & -4);

    for (i=top; i < base; i++)
        *i = 'Mark';
}


// A test routine used to USE the stack.

#define TYPE long

TYPE
Recurse(TYPE);

TYPE
Recurse(TYPE d)
{
    TYPE temp=d;

    if (d > 0)
        temp *= Recurse(d-1);
    else
        temp = 1;

    return temp;
}

main()
{
    long i;
    TYPE d;

#if 1
/*
   Increase the stack size by X bytes bytes.
*/
    SetApplLimit(GetApplLimit() - 20*(long)1024);
#endif




MarkStack();
i = CheckStack();

d = Recurse(500);
i = CheckStack();

d = Recurse(600);
i = CheckStack();

d = Recurse(700);
i = CheckStack();

d = Recurse(800);
i = CheckStack();

TestWindow();
i = CheckStack();


#if CHECK_PRINT
printf("%ld bytes used\n", i);
#endif

i = CheckStack();

}
--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  MoveWindow using unused stack portion as scratch?
Date: 25 Feb 92 03:46:22 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (David Dantowitz) writes:
>
>The following file contains five routines that demonstrate a problem
>I am having with unused portions of my stack being randomly written.
>I can't track this thing down to a code bug, but perhaps someone else can.
>
>It appears that MoveWindow is using a portion of the stack (that is currently
>unused) for temporary workspace.  It always uses the same offset from the
>top address of the stack (GetApplLimit()).  This can be tested by increasing
>the stack region.

MoveWindow, of course, calls CopyBits to move the contents of the window to
their new location. As part of its functioning, CopyBits can use up to all
but 1K of the stack for temporary buffers. Could this be what you are seeing?

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: [e-mail] (Gerald E Kaas)
Subject: Closing windows in MacApp
Date: 20 Feb 92 05:46:48 GMT
Organization: Iowa State University, Ames IA

I was wondering if there was a way to detect if the user has closed a window
that I opened without overriding TWindow or a TView.



- -------------------------

From: [e-mail] (Mark Lanett)
Subject:  Closing windows in MacApp
Organization: University of Illinois at Urbana
Date: Thu, 20 Feb 1992 06:56:46 GMT

[e-mail] (Gerald E Kaas) writes:

>I was wondering if there was a way to detect if the user has closed a window
>that I opened without overriding TWindow or a TView.

After the fact? You could search the window list in the document if you still
have the pointer; if the window is set to free on close then not finding the
pointer in the list will mean that it's been closed. Of course if it's *not*
set to free on close then you can just call IsVisible or something like that
on the window.

Under MacApp 3 one could also make a dependant on the window; that send some
sort of message (mClosing?) when they go away.

--
Mark Lanett                                                   [e-mail]
Software Tools Group, NCSA, University of Illinois at Urbana-Champaign



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  Closing windows in MacApp
Date: 25 Feb 92 03:41:51 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Gerald E Kaas) writes:
>I was wondering if there was a way to detect if the user has closed a window
>that I opened without overriding TWindow or a TView.

Mark Lannett has posted some handy tips here, but I just wanted to ask
a follow-up question: What's wrong with sub-classing TWindow? From my
memory of MacApp and from the way you ask your question, it seems that
sub-classing TWindow is the right thing. If so, why don't you want to
do that?

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



---------------------------

From: [e-mail] (Paul Potts)
Subject: Comm Toolbox problems with THINK C in XCMD environment
Date: 17 Feb 92 19:06:30 GMT
Organization: Instructional Technology Laboratory, University of Michigan

[I'm posting this for an officemate. If you reply by mail, send to
[e-mail]]

Our group is working on software which uses the CommToolBox to communicate from
a client to a server, using ADSP protocols.  We're also working on an XCMD so
HyperCard and SuperCard applications can access our server.

In working on this XCMD, I've been having some strange crashes, particularly
when using the NuLookup routine.  Other tahn suspecting my code, I wonder if I
can really use the CommToolBox library in an XCMD.  Symantec says in the THINK
C manual that you can use MacTraps and MacTraps2 since they do not access
globals.  It sounds like I should modify the other libraries to use A4, but I
can't since I don't have the source for them.

Any suggestions?

Mike Nowak,
U-M Office of Instructional Technology.
- -----


--
         -Paul [e-mail]-
"Wrong is wrong, even if it helps you." - Popeye



- -------------------------

From: [e-mail] (Roger W. Brown)
Subject:  Comm Toolbox problems with THINK C in XCMD environment
Date: 25 Feb 92 17:13:49 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Paul Potts) writes:

> In working on this XCMD, I've been having some strange crashes,
> particularly when using the NuLookup routine.  Other tahn suspecting my
> code, I wonder if I can really use the CommToolBox library in an XCMD.

I have succesfully used the CommToolBox in an XCMD. That was in THINK C
version 4, using a library that I converted from MPW. I have not tried
the one that comes with THINK C version 5 yet. But I asked Symantec if
it would work in a CODE resource as is and they said that it should. If
you do a "Get Info" on each piece of the library, you can see that no
data are allocated.

I did detect what appear to be some inconsistencies between the
interface files (Comm... .h) and the documentation for CTB version 1.0.
I don't have those with me right now, unfortunately.

One thing to consider (this caused weird crashes for me once) is the
use of XCMD globals and callback routines. NuLookUp has procedure
parameters. If you use these and the procedures that they point to use
data that are global to your XCMD, then make sure to RememberA4()
before calling NuLookup and SetUpA4() and RestoreA4() in those
procedures. Also (here was the one that got me), make sure that all
those calls dealing with A4 are IN THE SAME SOURCE FILE! (see page 110
of the version 5 User Manual).


- ---------------------------------------------------------------
Roger Brown                           [e-mail]
Courseware Development
Dartmouth College, Hanover, NH



---------------------------

From: [e-mail] (Gary Czychi)
Subject: OOP Power for TP Programmers  Was: Re: Book for TCL
Date: 20 Feb 92 17:41:26 GMT
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH

There is a book called

    Object-Oriented Programming Power for THINK Pascal Programmers

its 680 pages, but I don't know who wrote it, who published it and if it is
good.

If someone out there knows this book or is going to buy it, please send a
small review to this list or to me personally.

Thanks a lot,

  Gary

    Gary T. Czychi          University of St.Gallen

       [e-mail] (preferred host)
         czychi at csghsg52   (=bitnet)
           [e-mail]
             Switzerland
              -



- -------------------------

Subject:  OOP Power for TP Programmers  Was: Re: Book for TCL
From: [e-mail]
Date: Fri, 21 Feb 1992 16:35:32 GMT
Organization: Actrix Information Exchange

In article <[e-mail]> [e-mail] (Gary Czychi) writes:
> There is a book called
>
>     Object-Oriented Programming Power for THINK Pascal Programmers
>
> its 680 pages, but I don't know who wrote it, who published it and if it is
> good.
>
> If someone out there knows this book or is going to buy it, please send a
> small review to this list or to me personally.


I was recently given a copy of this book, but I haven't (yet) read it.

Details:

Title: Object-Oriented Programming Power for THINK Pascal Programmers
Author: Chuck Sphar
Publisher: Microsoft Press
ISBN: 1-55615-348-1
704 pages + 1 disk.  $39.95
Pub. Date: Aug 5, 1991


Hope this helps...

-- Bruce

--
[e-mail]   Twisted pair: [phone]
BIX: brucehoult                 Last Resort:  PO Box 4145 Wellington, NZ
"Cray's producing a 200 MIPS personal computer with 64MB RAM and a 1 GB
hard disk that fits in your pocket!"   "Great!  Is it PC compatable?"



- -------------------------

From: [e-mail] (Ian Robinson)
Subject:  OOP Power for TP Programmers Was: Re: Book for TCL
Date: 21 Feb 92 23:39:59 GMT
Organization: Gated to News by demon.co.uk


In article <[e-mail]>, [e-mail] (Ga-
ry
 Czychi) writes:
>There is a book called
>
> Object-Oriented Programming Power for THINK Pascal Programmers
>
>its 680 pages, but I don't know who wrote it, who published it and if it is
>good.
>
>If someone out there knows this book or is going to buy it, please send
>a small review to this list or to me personally.

I got a copy of this book last week. It is a very good introduction to object -

orientated programming using Object Pascal. It does not tell you how to use th-
e
Think Class Library as such. It rather attempts to teach OOP concepts by
building a collection of classes known as PicoAPP(which are included on disk).-


Check it out in a book store before buying if you can, A replacement TCL manua-
l
it isn't, but very good as an OOP tutorial and I'm glad I bought a copy.

Details of book:-
Object-Orientated Programming Power for Think Pascal Programmers
by Chuck Sphar
Published by Microsoft Press
ISBN = 1-55615-348-1
Price (US = 39.95 dollars) (UK = 35.95 pounds)

Ian Robinson

*************************************************************************
*  Ian Robinson                         Computer Department             *
*                                       Stewarts Supermarkets Limited   *
*  [e-mail]        224 Castlereagh Road            *
*                                       Belfast                         *
*                                       BT5 7AJ                         *
*                                       Northern Ireland                *
*                                       United Kingdom                  *
*************************************************************************



- -------------------------

From: [e-mail] (P. Hawthorne)
Subject:  OOP Power for TP Programmers Was: Re: Book for TCL
Date: 23 Feb 92 06:57:29 GMT
Organization: Reed College, Portland OR


  [e-mail] (GARY CZYCHI) writes:
: There is a book called Object-Oriented Programming Power for THINK Pascal
: Programmers...  If someone out there....

  [e-mail] (IAN ROBINSON) writes:
: I got a copy of this book last week. It is a very good introduction to
: object orientated programming using Object Pascal. It does not tell you
: how to use the Think Class Library as such. It rather attempts to teach
: OOP concepts by building a collection of classes known as PicoAPP(which
: are included on disk).-
: Details of book: Published by Microsoft Press.... ISBN = 1-55615-348-1

  Rumor says that it was intended to be an object oriented programming
book but that the whiz kid marketing snots at Microsoft Press thought
that the Object Pascal nature of the source code would reduce the number
of people who would buy it as a general text.
  Plodding along, trying to be as Gatesian as they could work up, they
hamstrung the impact of this damn fine analysis of the very fundamentals
of run time binding and getting recursion "for free," as it was put at
one of the SIGGRAPH panels this year.
  Microsoft should be busted up into hundreds of tiny pieces before they
can come up with a dial tone cable connection, but I digress.
  Of course, much of it is specifically around making Think Pascal
compile an actual library file. This was of use to me for an important
presentation, and I can see the worth of it.

It teaches one nothing about programming that one cannot learn from using
the Think Class Library with vigor. However, as an insight into the
approach of an object oriented evangelist pushing his code, it is much
more direct and expressive.
  Suffice it to say, if the idea of a compiler directive or a handle
bothers you, don't even bother with it.

    Theus ([e-mail])



- -------------------------

From: [e-mail] (Michael Kemper [Informatik])
Subject:  OOP Power for TP Programmers  Was: Re: Book for TCL
Date: 25 Feb 92 10:56:30 GMT
Organization: University of Kaiserslautern (Germany)

In article <[e-mail]>, [e-mail] (Gary Czychi) writes:
|>There is a book called
|>
|>    Object-Oriented Programming Power for THINK Pascal Programmers
|>
|>its 680 pages, but I don't know who wrote it, who published it and if it is
|>good.
|>
|>If someone out there knows this book or is going to buy it, please send a
|>small review to this list or to me personally.
|>
|>Thanks a lot,

The author is Chuck Sphar, Microsoft Press 1991

I saw the book last week, it seems to be good for learning OOP, but
doesn't give information about the Think Class Library, it just builds its own (little) Class Library. Disk is included and it costs DM 88,- (in Germany).

|\/|ichael |<emper
University Kaiserslautern
Germany



---------------------------

End of C.S.M.P. Digest
**********************